1. Field of the Invention
The present invention relates to a breakpoint logic unit, debug logic and breakpoint method for a data processing apparatus.
2. Description of the Prior Art
It is known to provide debug logic within a data processing apparatus to enable programs running on the data processing apparatus to be debugged by an external diagnostic system. An example of such a data processing apparatus is the processing system 10 of FIG. 1. The processing system 10 has a central processing unit (CPU) 50 provided therein, which is coupled to a memory system 65 via one or more buses to enable instructions and data to be passed between the CPU 50 and memory 65 as required by the CPU when executing one or more programs (as illustrated schematically by paths 55 and 60).
Debug logic 35 is provided within the processing system 10 for interfacing to an external diagnostic system 20. The debug logic 35 contains registers for use by the diagnostic system 20 for debugging programs running on the CPU 50 of the processing system 10. Features required for debugging include:    1. setting a “breakpoint”, such that the program halts execution when it attempts to execute an instruction at a given address;    2. single-stepping through a program, such that the program executes the next instruction to be executed and then halts execution; and    3. the ability to read from and write to the memory 65 and/or registers internal to the CPU 50.
Typically, the diagnostic system 20 will establish a breakpoint by sending a control signal over path 25 to the debug logic 35 to cause a selected address value to be stored within a value register of the debug logic, after which the debug logic 35 will compare that selected address value against the address of an instruction being fetched by the CPU 50, as indicated by the debug control signals 40 passed from the CPU to the debug logic 35. If it is determined that the instruction being fetched by the CPU matches the selected address stored in the value register of the debug logic, the debug logic 35 will then issue a breakpoint signal over path 45 to the CPU 50 to mark the instruction being fetched as being breakpointed. When the processor then attempts to execute that instruction, it instead halts execution and enters a debug state. The diagnostic system 20 can then via the debug logic 35 retrieve over path 30 contents from the CPU's registers and/or memory 65, as well as various other pieces of control information, in order to enable analysis of the current state of the processing system 10 to take place.
Breakpoints are used to solve a variety of problems. One such problem is to allow the user of the diagnostic system 20 to specify “run to here”. In such a usage scenario, the user selects a point in the program through the diagnostic system's user interface, and selects a “run to here” command. The diagnostic system then sets a breakpoint at that point by storing the relevant address in a value register of the debug logic, after which the processing system 10 is then set running. When a match is detected by the debug logic, and the breakpoint signal is hence issued, the processor will then stop running when it attempts to execute that instruction, and the diagnostic system will remove the breakpoint. The appearance to the user is that the program ran to a specified point. The user is unlikely to be aware that a breakpoint was used. However, the above approach only solves one class of the “run to” problem. In many other cases, the user may want to run until the processor is in a particular state rather than at a particular point. As an example, when using a system with different privileged modes or different secure states, there may be a requirement to “run until” the processor enters a particular mode or a particular state. There may also be a requirement to be able to combine these mode and state conditions. Whilst it might be possible to build specialised debug hardware aimed at supporting a particular complex breakpointing scenario such as one of those scenarios discussed above, this would be a costly approach, and would lack flexibility.
As discussed earlier, another feature required for debugging is single-stepping through a program. Traditionally, single-stepping is performed in one of two ways. In accordance with a first approach, the diagnostic system 20 is arranged to decode the “next instruction” and calculate which will be the instruction executed after that. Following this analysis, the diagnostic system 20 can then set a breakpoint at the address of that calculated instruction using the above described approach for setting breakpoints. This approach is however limited because it requires the diagnostic system 20 to understand the full behaviour of every instruction that can be executed on the processor 50. This limits the ability of the processing system designer to extend the instruction set with new instructions, because diagnostic systems may not understand these new instructions. It also presumes that the instruction will complete correctly, and hence that no exceptional circumstances will occur.
An alternative approach for single-stepping involves providing within the debug logic hardware a “single-step” control bit that instructs the processor to halt execution as soon as the next instruction completes execution. However, this second method is limited as it only allows simple levels of single-stepping, namely single-stepping to the very next instruction executed. Since this approach will always step to the next instruction that would be executed by the processor, then if an exceptional circumstance occurs the processor will halt at the first instruction of the related exception handler, which is not necessarily the desired behaviour. As another example, where the processing system runs multiple programs, and switches between them on the occurrence of interrupts driven by an external source, this leads to the user not being readily able to debug a single program, as the diagnostic system would “step into” the handlers for the interrupts from the timer system, and it would hence be very difficult to step to the next instruction from the program under test.
It would be desirable to provide an improved breakpoint mechanism which would allow the above described limitations of the prior art to be alleviated.
The “ARM7TDMI” debug logic produced by ARM Limited provided a pair of watchpoint registers and enabled the output of one watchpoint register to be routed as an input to the second watchpoint register in the pair. This structure would allow a breakpoint signal to be issued in the event of there not being a match between the address of an instruction fetched by the processor and a selected instruction address. This could be achieved by arranging the first watchpoint register to generate an output in the event of a match being detected between the fetched instruction address and the selected instruction address, and to use that output signal as an input to the second watchpoint register. The second watchpoint register can then be arranged to generate a match signal on any address, provided that a match signal has not been issued by the first watchpoint register. This match signal from the second comparator can then be used to generate a breakpoint signal, which would hence be set whenever the instruction address of the instruction being fetched did not match the selected instruction address. Whilst this would provide some improved flexibility with regard to single-stepping, it requires the use of a pair of interconnected watchpoint registers, which add significant complexity to the design of the debug logic.
Accordingly, it would be desirable to provide a breakpoint mechanism which would alleviate the limitations of the earlier-described prior art techniques, whilst avoiding any unnecessary increase in complexity of the breakpoint logic unit's design.